The 640 MEG Shareware Studio 2/The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO/virus/vl5_178.zip/VL5-178.TXT

Text File | 1992-12-07 | 46KB | 986 lines

 From [e-mail]  Thu Nov 12 11:32:25 1992
 Received: from fidoii.CC.Lehigh.EDU by abacus.fidoii.CC.Lehigh.EDU (5.65c/2.0)
     id AA27979; Thu, 12 Nov 1992 22:41:00 +0100
 Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA16807
   (5.65c/IDA-1.4.4 for <[e-mail]>); Thu, 12 Nov 1992 16:32:25 -0500
 Date: Thu, 12 Nov 1992 16:32:25 -0500
 Message-Id: <[e-mail]>
 Comment: Virus Discussion List
 Originator: [e-mail]
 Errors-To: [e-mail]
 Reply-To: <[e-mail]>
 Sender: [e-mail]
 Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
 From: "Kenneth R. van Wyk" <[e-mail]>
 To: Multiple recipients of list <[e-mail]>
 Subject: VIRUS-L Digest V5 #178

 VIRUS-L Digest   Thursday, 12 Nov 1992    Volume 5 : Issue 178

 Today's Topics:

 Re: Michelangelo (PC)
 Re: Outdated F-PROT?? (PC)
 How good is Norton Antivirus? (PC)
 VDS Pro 1.0 Released (PC)
 Re: SCAN 95b doesn't find MtE in EXE files (PC)
 Virus-like behavior of DOS 5.0 chkdsk (PC)
 Re: Is this a virus? (PC)
 PC-Week Article (PC)
 Re: Info Grain of Sand Virus (PC)
 Re: Newest and best scanner? (PC)
 Re: SCAN 95b doesn't find MtE in EXE files (PC)
 Re: SCAN 95b doesn't find MtE in EXE files (PC)
 Re: Filler virus - Need Help! (PC)
 PC Memory resident viruses detection (PC)
 Re: Is this a virus? (PC)
 Re: OS/2 system stopped due to virus (FAT partition)? (OS/2) (PC)
 Information (IBM VM)
 evaluation services
 Re: Denning Key Registration Virus
 Re: CHRISTMA: The "Card"! (CVP)

 VIRUS-L is a moderated, digested mail forum for discussing computer
 virus issues; comp.virus is a non-digested Usenet counterpart.
 Discussions are not limited to any one hardware/software platform -
 diversity is welcomed.  Contributions should be relevant, concise,
 polite, etc.  (The complete set of posting guidelines is available by
 FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
 your real name.  Send contributions to [e-mail].
 Information on accessing anti-virus, documentation, and back-issue
 archives is distributed periodically on the list.  A FAQ (Frequently
 Asked Questions) document and all of the back-issues are available by
 anonymous FTP on cert.org (192.88.209.5).  Administrative mail
 (comments, suggestions, and so forth) should be sent to me at:
 <[e-mail]>.

    Ken van Wyk

 ----------------------------------------------------------------------

 Date:    Wed, 11 Nov 92 08:58:52 +0000
 From:    [e-mail] (McAfee Associates)
 Subject: Re: Michelangelo (PC)

 Hello Brian C. Boorman,
 In article <[e-mail]> you write:
 >Does anyone know how Michelanelo is transmitted.  We have a serious
 >problem at this institution with it's spread.
 >
 >Basically my question is this: We know that it can transmit via a
 >5-1/4 disk in the A drive of a PC, but can it infect the boot sector
 >of a 3-1/2 floppy in the B drive?

 The Michelangelo virus is spread by booting from an infected floppy
 diskette.  When the infected floppy is booted from, the virus code is
 loaded and executed by the computer.  The virus is now installed in
 memory and will monitor the system for disk accesses.  When a disk
 access occurs, the virus checks the disk to see if its infected, and
 if not, infects the disk (network drives, Stacker compressed volumes,
 and other media which are accessed through a device driver are not
 affected).  I recall that the first copy of the virus we saw did not
 infect the second disk drive, however, a later version (February or
 March of this year?) infects both floppy drives.

 Regards,

 Aryeh Goretsky
 Technical Support
 - --
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 McAfee Associates, Inc.  | Voice [phone] | INTERNET:
 3350 Scott Blvd, Bldg 14 | FAX   [phone] | [e-mail]
 Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714
 95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
 Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR

 ------------------------------

 Date:    Wed, 11 Nov 92 09:54:57 +0000
 From:    [e-mail] (Lars J|dal)
 Subject: Re: Outdated F-PROT?? (PC)

 Nobody seems to answered this, so I'll try...

 [e-mail] (Low Profile) writes:

 >Frisk and all,
 >             I am currently using F-prot 2.04b on my machine and am
 >using Virstop.  I haven't had any problems until recently.  I wanted
 >to use F-prot 2.05 but since there was some mention on problems, i
 >decided to stick with 2.04b.  Anyway, now when i boot up my machine,
 >when it loads Virstop, it gives a message that sounds something like
 >"This version of F-prot is rather old and ..." overall what it is
 >trying to say is the version of f-prot i have is old and that i should
 >replace it.  Is this some form of virus, a way of your program
 >notifying me to switch or what?  This message comes on the screen
 >without fail for the past 2 weeks.  Any help would be great.  BTW,
 >what is the scope on the latest version of f-prot?  Thanx.

 No, it is not a virus or anything like that. It is simply F-prot that
 tells you that you are using an old version of the program and you
 should get a newer if possible.  Why? Not because of new options, but
 because the number of viruses grow fast. F-prot seems to be updated
 bimonthly and every new version detects at least 50 (if not 100) new
 viruses. Thus it is important to have a recently-updated program (of
 course this goes for other antivirus programs as well as F-prot).  The
 newest version is 2.06a. It is only a couple of days old, so maybe the
 archive sites only have 2.06 (which is a week old).

 +--------------------------------------------------------------------------+
 | Lars J|dal                  | Q: What's the difference between a quantum |
 | email: [e-mail]|    mechanic and an automechanic?           |
 |                             | A: A quantum mechanic can get his car into |
 | Aarhus University           |    the garage without opening the door.    |
 | Denmark                     |                    -- David Kra            |
 +--------------------------------------------------------------------------+

 ------------------------------

 Date:    Wed, 11 Nov 92 10:01:55 +0000
 From:    [e-mail] (Lars J|dal)
 Subject: How good is Norton Antivirus? (PC)

 How does Norton Antivirus compare to other virus programs, such as
 F-prot and Vscan, apart from that Norton is commercial? Norton is
 almost never mentioned here. Is that because it is commercial or
 because the other programs are better?  Please note that I'm NOT
 trying to start a flame war about "my scanner is better than your
 scanner". It must be possible to give some unbiased measures of an
 antivirus program, such as

 Approximately how many viruses does it detect?  Does it detect all the
 "important" viruses?  How often is it upgraded?

 etc.

 Thank you in advance!

 +--------------------------------------------------------------------------+
 | Lars J|dal                  | Q: What's the difference between a quantum |
 | email: [e-mail]|    mechanic and an automechanic?           |
 |                             | A: A quantum mechanic can get his car into |
 | Aarhus University           |    the garage without opening the door.    |
 | Denmark                     |                    -- David Kra            |
 +--------------------------------------------------------------------------+

 ------------------------------

 Date:    Wed, 11 Nov 92 05:39:54 -0500
 From:    [e-mail] (Mr. Tarkan Yetiser)
 Subject: VDS Pro 1.0 Released (PC)

    Hello everyone,

    We are happy to announce the availability of VDS Pro 1.0, an
 anti-viral package designed to help contain the spread of computer
 viruses by providing early detection and quick recovery. VDS Pro
 consists of various components, with an emphasis on integrity
 checking. It includes a network compatible virus scanner featuring
 both interactive and command line mode of operation with
 context-sensitive help at the touch of a key, a low-level interactive
 hard disk utility that simplifies dealing with boot sector viruses
 safely, an integrity checker that implements a "semi-automatic" expert
 system for detection of viral behavior, and a device driver to provide
 robust system area integrity checks and recovery.

    The programs in the VDS Pro package require MS/PC-DOS 3.0+, and an
 IBM compatible computer. The integrity checker is meant to be
 installed on a local hard drive to control virus entry points in a LAN
 environment or to provide a "fishing net" to detect viruses on
 stand-alone machines. The integrity checker is a BIOS-level
 implementation and in the current version does not support compressed
 drives, or the ones that require a device driver to be able gain
 access to the logical DOS partitions.

    We have found VDS Pro to be an excellent tool in containing the
 spread of computer viruses with its advanced features such as the
 decoy launching mechanism, self-healing capability, detailed audit
 log, emergency disk, user-definable frequency of checks, and reliable
 operation even when most stealth viruses are active in memory. It has
 many convenient features to allow unexposed users to take advantage of
 its powerful options without asking too many questions.

    Both VDSFSCAN (virus scanner) and VDS (integrity checker) support
 an external virus signature file to simplify updates and immediate
 response in the case of most unknown virus outbreaks. The integrity
 checker includes a built-in scanner to search programs newly added to
 hard drives for known viruses. It maintains a database of verification
 information for programs and system areas. Certain directories can
 also be excluded from checks for extra convenience in program
 development environments. The scanner is designed to be usable by
 anyone capable of reading English, and yet it is sophisticated enough
 to provide centralized LAN server-based installation for
 one-place-no-hassle updates. It can also be used on floppy-only
 systems.  VDSFSCAN can be run in the background under Windows 3.1
 enhanced mode, though it is not a Windows-specific application.

    VITALFIX is a powerful tool to remove boot sector viruses safely.
 It also has many options to perform such operations as looking for a
 relocated master or DOS boot record all over a hard disk,
 zeroing/backup/restoration/ manipulation of any sector on the hard
 disk, and construction of partition table and loader code.

    VDS package is priced reasonably enough not to put excessive burden
 on shrinking budgets of MIS departments. A licensed version of the
 package can be used indefinitely by the customer. New versions are
 provided for a small percentage of the initial licensing fee.
 Individual version costs $39, with a $10 optional printed manual (it
 is provided on a diskette). For more detailed information on prices,
 you can contact us at the following address:

                        VDS Advanced Research Group
                               P.O. Box 9393
                        Baltimore, MD 21228, U.S.A.
       e-mail:  [e-mail] (info only, not for sales)

    We also would like to say thanks to a few people who spared us some
 of their valuable time to test all or parts of VDS Pro package, and
 offered suggestions for improvement. Had these individuals not
 cooperate, several bugs would not have been discovered. Especially,
 Mike, Henri Delger, Paul Ferguson, Vesselin Bontchev, and Bill
 Whittington have been most helpful.

 ------------------------------

 Date:    Wed, 11 Nov 92 05:53:29 -0500
 From:    Otto Stolz <[e-mail]>
 Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)

 [e-mail] (Stefano Turci) writes:
 >  I run it on a high number of files infected with two Mte-based viruses
 >  ( Dedicated and Pogue) and it is able to detect all of the infected
 >  files, but how could I say if it will work for *EVERY* mutation and
 >  for *EVERY* Mte-based virus ?
 >  I think it's impossible.

 On 04 Nov 92 11:27:52 +0000 Vesselin Bontchev
 <[e-mail]> said:
 > You are right, it's impossible. That's why, our tests can only prove
 > that a scanner is NOT able to detect the MtE-based viruses reliably.
 > Otherwise we can only say that we have been unable to find an MtE
 > replicant that the scanner does not detect.

 Just to prevent a possible misunderstanding of Stefano's and
 Vesselin's claim:

 It is indeed impossible to tell it from tests alone, without
 considering the program's internal algorithms.

 However, it is probably possible (however difficult it may be) to
 prove that an Mte detector is reliable: The proof would be based on
 the following steps:
 1. Infer, from a sample of the MtE, the algorithm used to produce the
    various decryptors, and prove that the algorithm found and the MtE
    sample are indeed equivalent;
 2. infer from that algorithm the set of all decryptors that can possibly
    be produced from the MtE (of course not as a huge list of detailed
    code sections, but rather as a comparably moderate list of possible
    features, or patterns), and prove that the set is indeed produced by
    the algorithm,
 3. design an algorithm to detect all of these decryptors, reliably, and
    prove that it indeed does so.

 Step 1, called reverse engineering, is routinely performed by many
 virus researchers (though, maybe, without formal correctness proofs).

 On step 3, read "A Discipline of Programming" by Edsger W. Dijkstra.
 The basic idea of this book is to design a suitable proof first, then
 write the program in accordance with that proof. This is recommended
 reading for all would-be programmers!

 Step 2 is probably the most difficult one, as it cannot rely on
 established formal methods. Yet, it can probably be done -- as Rubik's
 Cube, and many more seemingly intractable problems, have been solved,
 eventually.

 In principle (but not practically) it could even been done by an exhaust-
 ive enumeration, as the set of all possibly produced code sections is
 finite (There are two easy proofs for this finiteness. Outline proof 1:
 The set of all starting states for the algorithm is finite, and the
 algorithm is deterministic, hence it cannot produce more different
 results than it has starting states. Outline proof 2: The length of the
 produced code sections is limited by the size of the largest disk avail-
 able, hence finite, hence the set of all possible code sections is the
 power set of a finite set, which is still finite -- and the MtE will only
 produce a small :-) subset of that power set.)

 Best wishes,
                     Otto Stolz <[e-mail]>
                                <[e-mail]>

 ------------------------------

 Date:    Wed, 11 Nov 92 09:09:43 -0500
 From:    vpk2![e-mail]
 Subject: Virus-like behavior of DOS 5.0 chkdsk (PC)

 This is an excerpt of a message I posted to comp.os.msdos.misc,
 that I thought might be of interest.

 (This is NOT an official report from Microsoft or AT&T. It's just
  my own friendly posting to try to help)


 Program: chkdsk
 O/S    : MS-DOS 5.0

 Symptoms: Users running chkdsk with the /f option have 256 copies
           of the FAT written onto their hard disk starting at the
           first copy of the FAT. The result being that all directory
           information and a significant amount of the data in the data
           area are irrecoverably destroyed.

 Affected users: Any users using 256 sector FAT's.

 How to tell if you're at risk:

           Run chkdsk WITHOUT the '/f' option and check the
           "Total allocation units on disk". If this number is
           more than 65280, you're at risk. DO NOT USE CHKDSK TO
           CORRECT ANY DISK PROBLEMS if this is the case. You'll
           trash your disk.

 Solution: Call Microsoft and request the 5.00A upgrade. They know
           about the problem and they've fixed it. They've also done
       some diddling with the following programs: (though I don't
           know what they did to them.)

     deloldos.exe    diskcomp.com    diskcopy.com
     doshelp.exe    dosshell.exe    dosswap.exe
     emm386.exe    expand.exe    format.com
     himem.sys    mirror.com    qbasic.exe
     recover.exe    setver.exe    undelete.exe
     xcopy.exe

 ______Opinions stated are my own. Transcripts available by request______
       ===
     =--====  AT&T Canada Inc.          John Benfield
    =----==== 3650 Victoria Park Ave.   Network Support Analyst (MIS)
    =----==== Suite 700
    ==--===== Willowdale, Ontario       attmail   : ~jbenfield
     =======  M2H-3P7                   email     : uunet.ca!attcan!john
       ===    [phone]            Compu$erve: 72137,722

 ____Eagles may soar, but weasels don't get sucked into jet engines._____

 ------------------------------

 Date:    11 Nov 92 16:02:34 +0000
 From:    [e-mail] (Kevin Marcus)
 Subject: Re: Is this a virus? (PC)

 [e-mail] (knazik bob) writes:
 >My 386 PC reports that I have 654360 conventional memory when I do a
 >"chkdsk" or a "mem" (DOS 5.0).  This is 1024 short of the expected
 >amount.  I seem to remember that there was a virus that caused this
 >result, but VSCAN finds nothing wrong.  Does anyone know if this is a
 >virus or just some weird hardware failure ?  Any help is appreciated.

 Well, it depends.  See, not ALL computers get 655360 bytes free.  For
 example, genuine IBM's are 1K under the 640K barrier.  It is possible
 you have an unknown virus, though I can't think of one which is 1K
 exactly; most MBR infectors take at least 2K.

 To do a quick check, what you could do would be get a System disk from
 a friend that is not infected, and boot with it.  RUn their copy of
 chkdsk.  If it says 655360, then you have a problem.  Otherwise it's
 prob. just your BIOS.  You could also try to run "fdisk/mbr" while at
 the C: prompt, and then reboot your computer immediately after. This
 will get rid of generic MBR infectors.  It does not matter if the
 virus is in memory at this time.  (This is true for SToned,
 Michelangelo, etc.).

 Additionally, some BIOS's allow for 1K below 640K to be reserved as a
 buffer.  Enter your CMOS and check through the options to see if you
 have this flag set.  Sometimes they'll allow you to switch from
 location 0:300 in memory to 1K below 640.

 Newer AMI BIOS' definately have this function, I do not know about
 others.


 ------------------------------

 Date:    Wed, 11 Nov 92 16:27:17 -0500
 From:    [e-mail] (A. Padgett Peterson)
 Subject: PC-Week Article (PC)

 Boy, this seems to be the week for it. Opened up the new (November 9)
 PC-Week and on page 141 the lead to the Buyer's Guide is on "Network-
 Operable Anti-Virus Software"

 The section starts with a page of tips, comments, and quotes that would
 have been very handy - in 1989 - but is sadly out of date today. Despite
 the header, no information on network needs is made and the listings make
 one wonder if the writers actually know what a network is !

 I expect the readers to be confused about exactly what the different
 products do since I certainly was 8*(. For instance one "Novell Netware, 3.0
 to 5.0" (confusing enough - the fine print indicates that "3.0-5.0" probably
 refers to MS-DOS -I think) product provides "..logging of virus activity by
 user name or node address..." - sounds like a server module, right ? But two
 columns over "Memory Resident Features" lists "TSR can be loaded in high
 memory". TSR ? (not NLM) High memory ? (Netware uses a flat model).

 Eventually some intelligence was gathered: if the product ran on everything
 under the sun (the bright one), it was something that could be loaded on
 an MS-DOS (or in at least one case on MACs) platform and could check/scan/
 validate anything that MS-DOS could reach. In other words, my 1600 byte
 CANARY written in 1989 to pick up the DATACRIME would qualify under all
 of the networks listed (except Appleshare - well maybe if the MAC was running
 SOFTPC 8*) and not require any memory, high or flat.

 On the other hand, if a product only ran on Netware then *maybe* it was a
 NLM (McAfee's NETSHIELD is an NLM but didn't say so - never did figure out
 what Central Point's "master NLM and slave NLM support" means.

 At any rate, of the 25 products listed (no ranking was presented), I suspect
 that only four acually provided separate server modules, the rest were
 simply DOS based anti-virals that either were able to examine connected
 server directories (as DOS directories), or were loadable by the client from
 the server (and available as "server packs"). Since the only criteria is
 for the program not to blow up on a drive that may not have a MBR, that
 might not respond instantly, or that might have a locked file, qualification
 is not difficult.

 Maybe to expect something more than a three-year-out-of-date commentary or
 less than the whole calabash claims from unrestrained vendors would be too
 much (well I know one journalist who could be accurate and demand accuracy
 but she is awfully quiet these days). Then again maybe a 1965 Pontiac 2+2
 could do 0-60 in 3.8 seconds.

                     Warmly,
                         Padgett

   (lets see, 421 Milt Shornack cubic inches, gear for 60 mph in first,
    open exhausts, Firestone cantilever racing tires, and a Smokey Yunick
    stopwatch...)

 ------------------------------

 Date:    11 Nov 92 21:55:55 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: Info Grain of Sand Virus (PC)

 [e-mail] (Ale de Boer) writes:

 > Can anyone give information about the Grain of Sand virus. TBSCANX
 > noticed this virus while copying a file allegedly containing it. Scans
 > with McAfee turned up nothing, nor did TBSCAN. I could not find any
 > information about the GoS virus in VSUMX.

 A more widely used name for this virus is Maltese Amoeba. In our tests
 SCAN 97 was able to detect reliably the infected samples, so you
 probably have a false positive. Just in case, try F-Prot 2.06a. It is
 important to verify whether you really have this virus or it is only a
 false positive, since the virus triggers on November 15 and destroys
 the information on your hard disk.

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    11 Nov 92 22:02:00 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: Newest and best scanner? (PC)

 [e-mail] (Bartjan Wattel) writes:

 > One of *the* best scanners I know of, is:

 You forgot to tell -why- you are considering it as one of the best
 ones. IMHO, its best feature is that it is user-programmable. It uses
 a text file, which contains a database of scan strings. The scan
 strings can contain wildcards and in fact the wildcard language
 supported is rather powerful. For viruses that cannot be detected with
 a scan string (i.e., the polymorphic viruses), it supports the
 so-called AVR modules - small assembly-language programs that
 implement algorithmic search for these viruses and are loaded at
 runtime.

 In fact, TbScan contains only the scanning engine; the virus-specific
 stuff is provided additionally. The most popular eternal database of
 virus signatures is supported by Jan Terpstra.

 TbScan is also extremely fast and uses some tricks to speed up the
 scanning. For instance, it traces the entry point of the files, until
 it reaches a place where the virus should reside and then scans only
 this place, thus reducing the disk access significantly.
 Unfortunately, it sometimes tries to be too smart and can skip the
 place where the virus signature begins. That's why I personally prefer
 HTScan, which can use the same format of the signature database and
 the same AVR modules, but instead of smart tricks just plainly scans
 the whole file. Indeed, I think that there is an option to make TbScan
 to scan the whole file.

 As far as I know, the latest version of TbScan is 4.3.

 > TBScan is shareware, and can be uploaded from several BBS's. For the
 > most recent version, call the 'data'-phone number (all baudrates).

 More important for the readers of this newsgroup is that it is
 available for anonymous ftp from Simtel20 and its mirrors, in the
 MSDOS.TROJAN-PRO directory.

 > TBScan uses identity scanning, but als heuristic scanning. The
 > heuristic scanning algorithm is rather new and seems to be (one of)
 > the best there is.

 The only problem is that you cannot turn it off. Sometimes I need just
 to scan for a particular set of strings in many files, and want a
 report about what exactly strings have been found which files. I don't
 need the report file to be cluttered with information which files are
 considered suspicious by the scanner, because some of its heuristics
 have fired... In version 4.3 it is possible to turn off the (long)
 explanation of each heuristic each time that it is used, but it is
 still not possible to disable the heuristics completely.

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    11 Nov 92 22:22:31 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)

 [e-mail] (Jimmy Kuo) writes:

 > The argument for the second opinion says that if you detect the
 > infected form of the children, you will know if something is going on
 > in the computer.  Once something is known to be affecting the
 > computer, theories related to integrity checking can take over.  Files
 > such as those created above and certain files in reviewers'
 > collections cannot spread in that convoluted form and need not worry
 > endusers.  (A version of this argument applies to whether it is
 > necessary to detect absolutely 100% of MtE mutations, i.e.  integrity
 > checking takes over.)

 I tend to disagree. First, according to the above argument, you can
 always use an integrity checker to detect the second-generation
 infections, so you don't need a scanner at all. In fact, one of the
 arguments why the integrity checkers cannot replace the scanners
 completely, is that when you notice the infection, you usually want to
 find and remove all sources of infection, including the file that
 brought the virus to your system. Also, scanners are useful for
 scanning the software -before- you run it (something that the
 integrity checkers cannot do), therefore, the user wants to be able to
 find the viruses at that stage, not after the virus has been released
 in the system.

 Second, all the scanners mentioned by the original poster claim to be
 able to scan inside LZEXE compressed files. Therefore, if those claims
 are correct, they should be able to detect the virus.

 Third, some scanner -were- able to detect the virus.

 However, I agree with you, that in general the virus droppers (because
 what the original poster has done has been exactly to create a
 dropper) are not a serious problem.

 > It should be the form that propagates that we worry about.  And though
 > you didn't note it, I'm sure all the files infected by your creations
 > were detected by all the packages above.  Thus end-users need not
 > worry about your peculiar forms of MtE files because you're not going
 > to put those files on anyone else's computer.  :-)

 Problem is, it is perfectly possible to create an MtE-based virus,
 converted in the way described in the original message, which will
 propagate in THAT FORM. Recall that we already have several viruses
 that are propagating in LZEXE or PKLITEd form...

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    11 Nov 92 22:31:54 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)

 [e-mail] (Fridrik Skulason) writes:

 > In my case the reson I miss this particular sample is simple.  I scan
 > inside LZEXE-compressed files, but only for signatures - that is, I
 > uncompress the virus in memory, and run my scanning engine over it.
 > If I uncompressed to disk, and stripped off the COM/EXE conversion, I
 > would detect it, but it would slow the scanner down considerably.

 But why uncompressing it to disk? Can't you continue to do it in
 memory? The scanner in Untouchable is able to scan inside multiply
 compressed files (e.g., it can detect a virus that has been PKLITEd,
 then LZEXEd, then ICEd, etc.), so it should be possible to do it...

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    12 Nov 92 00:28:20 +0000
 From:    [e-mail] (Wes Ames)
 Subject: Re: Filler virus - Need Help! (PC)

 [e-mail] (Vesselin Bontchev) writes:
 > It is much more
 > probable that you are using some other anti-virus software, like CPAV
 > or TNTVIRUS, that does not encrypt its scan strings and is causing a
 > false positive. If you are using CPAV, read the manual - it clearly
 > says that it is not compatible with any other anti-virus software. So,
 > throw away either CPAV or SCAN. If I were you, I would throw away
 > CPAV...

 I have seen several references similar to the above, and I would
 appreciate some clarification.  I use several different anti-virus
 packages in our "anti-virus toolkit", including CPAV.  My experience
 has been that early versions of CPAV did indeed have a problem with
 viral scan strings in memory, but the problem has been eliminated in
 more recent versions.  Not only are the strings encrypted, but they
 are specifically overwritten when the user exits the app.  That has
 been my understanding of the current product - have you seen something
 different??

 Wes Ames                           |
 [e-mail]          |
                                    |

 ------------------------------

 Date:    12 Nov 92 08:45:57 +0000
 From:    [e-mail] (Paul Rolland)
 Subject: PC Memory resident viruses detection (PC)

 Hello,

 Because I'd like write some code to have my programs doing a quick
 memory check when starting before doing anything else (disk access or
 so), I'd like to have information on the way to detect already
 installed viruses.  I know some of them (at least 100) use hooked
 interrupts to check if they are alreasy present. Could some one give
 me these vectors and the tests to perform to see if a virus is memory
 resident ?  Any help would be greatly appreciated !

 PS : I already have the ones described in Ralf Brown's interrupt list.
 I don't want the code of the virus but just the interrupt to call to
 see if it is present.

 Thanks

 Paul Rolland, [e-mail]
 - ---
 A bug can be changed to a feature by documenting it. Developpers know !
 - --------------------- DISCLAIMER -------------------
 All the opinions I express in this posting are mine, but I'm
 ready to share them with anybody interested :-)

 ------------------------------

 Date:    12 Nov 92 09:33:21 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: Is this a virus? (PC)

 [e-mail] (knazik bob) writes:

 > My 386 PC reports that I have 654360 conventional memory when I do a
 > "chkdsk" or a "mem" (DOS 5.0).  This is 1024 short of the expected
 > amount.  I seem to remember that there was a virus that caused this
 > result, but VSCAN finds nothing wrong.  Does anyone know if this is a
 > virus or just some weird hardware failure ?  Any help is appreciated.

 This is in the FAQ. While there -are- viruses that reduce the memory
 size by 1 Kb, they are not widespread, so it is rather unlikely that
 you have a virus. Most resident viruses reduce the memory size by a
 larger amount of bytes - usually at least 2 Kb.

 Check your CMOS setup - maybe you have told it to allocate 1 Kb from
 the top of memory for its data area. Are you using a SCSI controller?
 Any kind of additional operating system, like Unix? Is MS-DOS loaded
 high? With what kind of memory manager? All these reasons can cause
 memory reduction...

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    Wed, 11 Nov 92 18:42:34 +0000
 From:    [e-mail] (McAfee Associates)
 Subject: Re: OS/2 system stopped due to virus (FAT partition)? (OS/2) (PC)

 Hello Wey Jing Ho,

 you write:
 >My PC has just been infected by an unknown virus (both McAfee Scan
 >Version 97 and CPAV failed to identify it/them). SCAN only report that
 >all of the hard disk boot sectors have been modified (as compared to a
 >CRC file created before the infection). I have both MS-DOS 5.00 and
 >OS/2 (with the latest CSD) installed with DOS on FAT and OS/2 on HPFS.
 [...deleted...]

 If you are running an OS/2 Dual Boot system, SCAN will report that the
 boot sector has been modified when you switch from DOS to OS/2.  This
 is because OS/2 swaps the boot sector on the drive depending on which
 operating system you are using.

 Regards,

 Aryeh Goretsky
 Technical Support

 - --
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 McAfee Associates, Inc.  | Voice [phone] | INTERNET:
 3350 Scott Blvd, Bldg 14 | FAX   [phone] | [e-mail]
 Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714
 95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
 Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR

 ------------------------------

 Date:    Wed, 11 Nov 92 17:40:57 -0500
 From:    "Meyer, Leonardo Sant'Anna" <[e-mail]>
 Subject: Information (IBM VM)

 Gentlemen:

         I would like some informations about the known VM viruses:

 - -> if exists any anti-viruses programs
 - -> if exists, how can I obtain them ?

                                         Thank you.

                                            Meyer, Leonardo Sant'Anna

                                                  BZ13INQ AT BRUERJ

 ------------------------------

 Date:    Wed, 11 Nov 92 17:31:08 +0000
 From:    gator.rn.com![e-mail] (Sara Gordon)
 Subject: evaluation services

 i am looking for information regarding anti-virus product evaluation
 services.  specifically: what services are available; what are their
 costs, what is included, what are the strengths and weaknesses of
 each one; what have you found to be the accuracy/efficiency of the
 one(s) you are familiar with.

 if you have used such an evaluation service, please e-mail me
 to the [e-mail].     i am talking about specific evaulation
 services, not 'test results' such as posted in this newsgroup.

 if you offer such a service, please also e-mail me.


 thank you.


 - --
 - ----------------------------------------------------------------------

 Talk to me about computer viruses.        [e-mail]
                                           [e-mail]


 ------------------------------

 Date:    12 Nov 92 09:22:30 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Re: Denning Key Registration Virus

 [e-mail] (Lynn R Grant) writes:

 > This is sort of like the IBM XMAS virus, but it doesn't take any code.
 > All you have to do is post a highly controversial item on a well-read
 > forum, and wait for the responses to bring the network to its knees.

 :-). Yeah, but it must also be a non-moderated newsgroup, like
 sci.crypt, or sci.math, otherwise the moderator might spoil you the
 pleasure... :-))

 Regards,
 Vesselin

 P.S. Since I am wasting the bandwidth anyway... If [e-mail]
 reads this - I am receiving your messages, but am unable to reply -
 the mail bounces. Please supply a better reply path, possibly
 involving one of the gateways to uucp in South Africa.
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    Wed, 11 Nov 92 10:36:28 -0500
 From:    Otto Stolz <[e-mail]>
 Subject: Re: CHRISTMA: The "Card"! (CVP)

 On Fri, 06 Nov 92 12:21:47 -0800 Robert M. Slade <[e-mail]> said:
 > HISVIRH.CVP   921022
 >
 >                      CHRISTMA EXEC - the card

 Though Robert Slade's reports are usually quite reliable, I have to
 mend some (admittedly: minor) errors and omissions in this particular
 one. On this occasion, I'd like to thank Robert for the valuable
 service he has provided to the VIRUS-L subscribers.

 > In December of 1987 IBM mainframe computers in Europe, connected via
 > the EARN network, experienced a "mailstorm".

 Actually, the mailstorm was not confined to Europe. EARN is only part
 of a world-wide academic network; other parts of this network are
 known as "Bitnet", and "Netnorth". The mailstorm origined in Europe
 (in the University at the small German town Clausthal-Zellerfeld, if I
 am not mistaken), and wandered once around the globe, in about three
 days. Allegedly, it also hit the IBM internal network, VNet, which was
 connected to Bitnet via a gateway that would let pass information only
 between selected partners.

 However, not all computers in the network were affected alike.
 EARN/Bitnet/Northnet (in the sequel, I'll use "Bitnet" as an
 abbreviation) is a heterogenious network, connecting computers of many
 different brands.  CHRISTMA EXEC can only reproduce in the CMS, one of
 the operating systems that run in IBM, and compatible, hosts. The CMS
 hosts were busy reproducing and sending the EXEC, while the other
 hosts just suffered from the dramatically increased network load.

 > This mailstorm,
 > however, was of unprecedented severity.  It shut down whole sections
 > of the net, at least as far as effective work was concerned.

 Yes. The reason being, that Bitnet is a store-and-forward network.
 I.e., a message normally travels through several hosts, until it
 eventually reaches its destination. Hence, the whole network suffered
 from the increased load, irrespective of the fact that the items
 originated only from a comparably small percentage of its hosts.

 > For many, probably for most, users, email is simply text.  A select
 > group are involved with the exchange of programs or other binary
 > files, [...]

 Bitnet provides three independent transport services:
 1. Mail (as implied by the paragraph partially quoted),
 2. arbitrary files (*not* embedded in Mail items),
 3. short, interactve messages.

 > The CHRISTMA EXEC was a message that contained such a program.

 No. CHRISTMA EXEC was a source file that contained comment lines.

 > "Christmas card" messages with this system can be more than just the
 > usual "ASCII tree". [...]

 Of course: programs can do anything conceivable (if technically
 feasable).

 > The message header
 > contained a note that "Browsing this message is no fun at all.  Just
 > type Christmas .." [...]

 Rather, a similar message was contained in a screen-sized comment
 block in the program which came after five (or so) screens of rather
 boring REXX statements of the sort "display so-and-so many asterisks,
 then so-and-so many blanks...". Of course it said "Reading dull
 programs like this one is no fun.." or something along this line.

 > Typing either "Christmas" or "Christma" would generate the "card" [...]

 You had to do a RECEIVE command first (or at least hit the equivalent
 PF9 key). This would generate a file named CHRISTMA EXEC on your disk.
 Then, "Christma" would be the normal command to interpret the REXX
 programm contained in that file; "Christmas" would work also, as CMS
 chops the command verb after 8 characters.

 > However, at the same time that it was displaying the tree
 > on the screen, it was also searching for the NAMES and NETLOG files
 > associated with the user's account. [...]

 These are CMS specific files. This is the main reason why CHRISTMA
 EXEC could only replicate in CMS systems, and not in other systems --
 even if they had a REXX interpreter, which at that time very few
 non-CMS systems had. (Personal REXX for MS-DOS appeared in 1985, REXX
 for TSO only in 1988.)

 > This provided a list of other
 > users that either sent mail to or received mail from this account.
 > The important thing was that it was a list of valid email addresses.
 > The CHRISTMA EXEC would then mail copies of itself to all of these
 > accounts.

 The NETLOG file is sort of a certificate of posting: it contains a
 list of files and mail items sent to, or received from, other users
 (including the network addresses involved). The NAMES file is sort of
 a personal directory: it contains only personal notes on people the
 user knows, mostly including their network addresses.

 > The important point, technically, was that all of the accounts were
 > valid.

 Well, most of them...

 > As a side benefit, all of those accounts would be used to
 > receiving mail from the account that had just read it.  And they
 > would tell 40 friends, and they would tell ...

 Hence, CHRISTMA EXEC could easily pass the Bitnet-VNet gateway.

 May I add that it was a traumatic experience for many users to run the
 EXEC (not for me, as I usually read programs donated to me before I
 run them :-) At that time, most Bitnet nodes sent an interactive
 message back to the original sender whenever they had forwarded a
 file, or a mail item (as if every post employee who handles your
 letter would send you a telegram to acknowledge that fact). This
 resulted in one to about twenty lines (depending on the distance) on
 the senders screen for every addressee the file was sent to,
 interrupting normal work and filling the screen (which had then to be
 cleared to proceed).

 > [...]

 In short: CHRISTMA EXEC came as a program that had to be received and
 run by the user. The program would run only under the CMS operating
 system.  When run, the program would send exact copies of itself to
 other Bitnet users known by the user who had run the program.

 I hope I am not perceived as being too picky in saying this. Thanks
 again to Robert Slade.

 Best wishes,
                     Otto Stolz <[e-mail]>
                                <[e-mail]>

 ------------------------------

 End of VIRUS-L Digest [Volume 5 Issue 178]
 ******************************************